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System and method for building a software application 

The present invention relates to a system for building a software application 
comprising an input/output device, memory means and processing means connected to 
the input/output device and memory means, the processing means being arranged for 
defining an application specification, which allows execution of the software 
application by entering the application specification in a generic application engine 
running on a computer system. In a second aspect, the present invention relates to a 
method for building a software application by defining an application specification, 
which allows execution of the software application by entering the application * 
specification in a generic application engine running on a computer system. 

In present systems and methods for building software applications, either a 
standardised software package is bought by a company, and its business processes 
adapted to the software package or a software application is designed, programmed and 
tested to suit the specific needs of a company. In the first case, such a software package 
lacks flexibility in use, is often difficult to integrate into existing systems and usually 
offers too much, too little or the wrong functionality. In the second case, the complete 
software development before operational use is often long and expensive. 

Principal to these known software development strategies, is that it involves 
programming and testing of software code. Different specialists with different 
competencies are involved in a sequential, and often also iterative, maimer before ah 
operational software application is obtained. This requires large investments, both in 
time and cost. 

The present invention seeks to provide a system and method for building a 
software application which shortens the time to operational use of a software 
application, and provides a better cost efficiency for delivering an operational software 
application. 

The foundation of such a system and method is described in pending patent 
application PCT/NLO 1/00^26, of the same applicant as the present patent application. 

According to a first aspect of the present invention, a system is provided 
according to the preamble defined above, in which the processing means are further 
arranged to derive the application specification using the input/output device, and to 
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store the application specification in the memory means, the application specification 
comprising: 

a) a specification of a plurality of data classes relevant within the software 
application, a data class being a description of objects, and the plurality of data classes 
forming a structure by means of relations; 

b) a specification of at least one user group of the software application, a user 
group being defined as a group of users having common roles with regard to the 
software application; 

c) an assignment of permissions to the at least one user group with respect to the 
plurality of data classes. 

An application specification is an abstract, but exact, specification of a software 
application. This can be a software application in any state, e.g. a software application 
that is already running, or a software application to be built. The specification is 
'abstract', because it concentrates on data classes, user groups and permissions. It can 
define a complete software application without having to mention user interface details. 
The specification is 'exact', because it sufficiently describes a software application to 
generate the complete operational software application. An application specification is 
usually the result from an information analysis, but can also be (partly) derived from 
reading meta data of an existing database. 

In this description of the invention, the focus is on a "black box" generic 
application engine. In this style of operation, the application specification is loaded into 
a generic application engine, after which the generic application engine executes the 
desired behaviour of the software application. However, in an alternative style of 
operation, the process can be subdivided in separate steps. First, executable software 
code is created from (parts of) the application specification (in any programming 
language). In a second step this generated software code may even be modified by a 
human programmer in order to change technical details, functionality and/or 
appearance. Finally, the generated (and possibly modified) software code can run, 
possibly together with standard components of the generic application engine. In this 
style of operation, the original application specification can still be used to control the 
behaviour of the software application. This alternative style of operation delivers more 
control to the programmer, and provides more possibilities to adapt the software 
application. 
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The alternative style of operation can be implemented, using the same application 
specification as in the first style, and producing software code that, when executed, 
provides the same functionality as in the first style. There are several ways to generate 
software code from the application specification, mainly dependent on the desired 
relation between the generated code and the standard components. Since the concept of 
code generation from a model is common in the field, this style of operation is not 
described in further detail. From the description of the first style, it will be apparent to 
the person skilled in the art, how to create an implementation of the alternative style. 

The term 'data class' as mentioned in this description, refers to a 'class* in 
standard object oriented modelling (usually a class is known as a description of objects 
having common characteristics). However, the essentials of this description and this 
invention can also be applied on 'entities' as they are known in the area of conventional 
data modelling 

The term 'relation* as mentioned in this description refers to a structural 



relationship between two data classes, commonly known as an 'association* (e.g. see 



relations themselves might be of type: one-to-one, one-to-many or many-to-many, as is 
commonly known in the area of entity relationship modelling. 

When two data classes are related, the data class on the one-side of the 
relationship (if any) is called the 'foreign class', while the data class on the many-side 
of the relationship (if any) is called the 'connected class'. A connected class usually has 
multiplicity *, with respect to this relation. A foreign class usually has multiplicity 0..1 
or 1 with respect to this relation. At run time the relationship will lead to related 
objects. An object of the foreign class is called 'foreign object*, while an object of the 
connected class is called 'connected object'. When a data class A has a connected class 
B, and class B has a connected class C, then C is an indirect connected class of A. 

The term 'user 1 as mentioned in this description may be understood as being an 
individual user, interacting with the software application via a (graphical) user interface 
(input and output), or a further software or hardware application (using appropriate 
interfaces). In simple software applications, there may be one single user group, being 



Unified Modeling Language). Each relation also has 'multiplicity*, which is an 
indication of how many objects may participate at either end of the relation. The most 
common multiplicities are 1, * (0 to infinity), and 0..1 (either none or one). The 
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, an anonymous or default user group. It is possible that this default user group is not 
explicitly specified. 

In a second aspect, the present invention provides a method as defined in the 
preamble above, in which the method comprises the step of deriving the application 
5 specification, the application specification comprising: 

a) a specification of a plurality of data classes relevant within the software 
application, a data class being a description of objects, and the plurality of data classes 
forming a structure by means of relations; 

b) a specification of at least one user group of the software application, a user 
1 0 group being defined as a group of users having common roles with regard to the 

software application; 

c) an assignment of permissions to the at least one user group with respect to the 
plurality of data classes. 

With the system and method according to the present invention, it is possible to 

1 5 develop an operational software application to suit specific needs by only specifying 

the functionality of the software application. The software application is built, with 

considerably less detailed programming. This also allows for easier maintenance and 

future upgrades, as only the application specification needs to be updated. 

The application specification used in the present invention serves various targets. 

20 First, it can be entered in the generic application engine to create the running software 

application. Secondly, from the application specification scripts can be derived to 

create or modify the database structure that is used to store the application's data. 

Moreover, the application specification may be useful in other areas, such as 

management and support or other organisational areas, e.g. education and training. 

25 The present invention thus allows to make a software application with any usual 

functionality of a modern software application on a variety of fields, such as archiving, 

call centre applications, workflow, customer relationship management, e-commerce, 

content management, etc. The present system and method are particularly advantageous 

i 

when using (multiple) databases with complex data models, when using various user 
30 groups with different authorisations, or when using deduction rules. 

The generic application engine comprises functionality which is often present in 
software applications, i.e. database operations, business logic/rules, presentation 
functions, user input/output interfaces, logging and monitoring. The generic application 
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engine may use known technical standards, such as SQL, XML, XSL, JAVA, HTTP, 
SOAP. 

The generic application engine allows to select data, read data, lock data, join 
data, sort data, insert data, copy data, update data and delete data in a database, to 
import and export data from/to files, such as XML-files, and to synchronise database 
copies. Business logic can be supported and executed in several ways. Deduction rules 
(formulas, etc.) may be automatically executed in order to deduce data. Validation rules 
can be executed to validate user input. Additional constraints might be used to create 
specific selections of data or lookup lists. Event triggers can be used to implement work 
flows. Finally, specific procedures can be implemented that can be executed on user 
requests. 

For presentation of data on a screen, the generic application engine uses various 
screen layouts, such as tree, tabular and cross table representations. Data may be 
selected, presented (e.g. using simple graphics), modified and uploaded. Other input 
and output is possible using the generic application engine, e.g. using interfaces to send 
and receive e-mail, faxes, sms, etc., read and write files (e.g. txt, xml, csf), or exchange 
data with other programs, e.g. using HTTP, CORBA or SOAP. Also, the generic 
application engine is arranged to log all use of the software application, and to process 
the logged data. 

The term * select' in this description in relation to data classes and objects, refers 
to the action of constructing criteria, and applying these criteria on a data class in order 
to get a subset of objects. The values of one or more fields of the selected objects are 
presented in a list or table. The term 'select' can be exchanged by the term 'search'. 
From this list or table the other details of each object can be accessed, e.g. by selecting 
a row and/or activating a button. 

The terms 'modify* and 'modification', used in this description in relation to data 
objects, refer to one or more of the following actions: insert, copy, delete and update. 
The term 'update' only refers to altering values of fields of existing objects. 

In the area of data processing, other systems and methods are present, trying to 
cope with the same problems as the present invention. Common in the field is the 
automatic construction of simple user interfaces for selecting, reading and editing data 
of one data class, derived from a data model. However, none of these methods and 
systems is as extended as the present invention. The present invention creates the 



possibility to deliver complete software applications, with a set of interrelated 
input/output devices, e.g. screens, each screen having integrated functionality for more 
then one data class (e.g. provided with trees or tab panels), and providing exact 
functionality for different users (based on roles and/or permissions), without having to 
specify the input/output devices themselves. 

In an embodiment of the present system or method, the application specification 
comprises for each of the plurality of data classes a specification of a plurality of fields, 
each field representing an element for storing data values related to an object. 

In a further embodiment of the present system or method, the application 
specification may comprise for each of the plurality of data classes a specification of a 
plurality of categories, which can be used to structure all data related to an object. This 
structure is used by the generic application engine to present data to the user in a 
comprehensible way. 

In another further embodiment, the application specification may comprise a 
specification of a plurality of domains, a domain being a list of lookup values that can 
be referenced to from the specification of fields. Domains are used to simplify 
selecting, reading and modifying objects. 

According to an even further embodiment, for a specific combination of user 
group and data class, or a specific combination of user group and field, the permissions 
are chosen from the set of: select permission; export permission; read permission; 
update permission; insert permission; copy permission; delete permission. The value of 
each permission is one of the group of: no; yes; follow foreign object; own; constraint. 
This allows to define the interrelationship between user groups and data classes and/or 
fields in a sufficient scope to be able to develop various software applications. 

In a further embodiment, the application specification comprises a computational 
specification for describing further computational parts of the software application. 
Certain software applications require additional logical operations on their data, which 
can not be specified using the application specification as described above. In this 
embodiment, a more broacl spectrum of possible software applications may be 
developed using the present inventive system and method. 

The application specification may in a further embodiment comprise an 
appearance specification far defining non-functional parts of the software application, 
such as user interface parts. The generic application engine includes standard 
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input/output of data from the software application. Using an appearance specification, 
the layout of the presented data may be altered and specified to specific user needs. 
Further advantageous embodiments are given in the other dependent claims. 
In a third aspect, the present invention relates to a computer program product 
S comprising an application specification as obtained by the present system or method, 
which when input in a generic application engine running on a computer system, 
provides the computer system with the functionality of the software application 
associated with the application specification. 

The present invention will now be described in further detail using a number of 
10 exemplary embodiments, with reference to the attached drawings, in which: 

Fig. 1 shows a schematic view of the execution environment of a software 
application according to the present invention; 

Fig. 2 shows a schematic view of the composition of an application specification 
according to an embodiment of the present invention; 
1 5 Fig. 3 shows a schematic view of a system used in the present invention to build a 

software application. 

In Fig. 1, a schematic view is shown of the execution environment of a software 
application according to an embodiment of the present invention. The schematic view . 
shows three parts of the software application environment, the development part 1, the 
20 run-time execution part 2 and the input/output part 3. 

A software application is developed according to the present invention using a 
specification editor 4 to analyse the software application and construct an application 
specification. The specification editor 4 produces the application specification 10, e.g. 
in the form of a XML file, in a manner to be discussed below. 
25 The specification editor 4 may comprise a processor 20 with associated memory 

21 and an input/output device 22, as shown schematically in Fig. 3. Of course, it will be 
apparent to the person skilled in the art that the specification editor 4 may be 
implemented using e.g. a computer, or other processing means and related peripheral 
equipment known in the art. 
30 The heart of the software application execution is the generic application engine 

5, running on a computer system. This generic application engine 5 provides the 
standardised functions which may be used by a software application. In combination 




with the application specification 10, the generic application engine provides the 
behaviour of the software application, using data residing in a database 6. 

The generic application engine 5 is connected to a number of possible interfaces 
for input and output to a user. A user may be a human user, using a (graphical) user 
5 interface, or a further software or hardware system using appropriate interfaces. The 
human interface may be implemented in a variety of manners, of which some are 
shown in Fig. 1. A web interface 1 1 may be used to interact with the software 
application. Alternatively, a windows interface 12 may be used. Both alternatives may 
be used in an Internet or Intranet environment, or on a stand-alone (PC-based) system. 
10 Other user interfaces may be e-mail or sms interfaces 13, or even a file interface 14. 

The database 6 which is being used by the software application, comprises data. 
These data may, in addition to being used by the software application according to the 
present invention, be used for other purposes, using analysis and reporting tools 15, 
which are known per se in the field of database processing. 
1 5 Fig. 2 shows the composition of an application specification 10 according to an 

embodiment of the present invention. The application specification 10 comprises at 
least a regular specification 7, which defines the basis of a software application. For 
certain software applications, it is conceivable that the application specification 10 only 
comprises a regular specification 7. For other software applications, the application 
20 specification may comprise a computational specification 8, which can include 
additional functionality to a software application, such as flow charts, constraints 
and/or macro's. Finally, the application specification 10 may comprise an appearance 
specification 9, which defines application specific elements of the user interface. 

The regular specification 7 may be assembled interactively using the specification 
25 editor 4. The core of the regular specification is formed by a definition of data classes 
and user groups, as well as the roles assigned to the user groups with respect to the data 
classes and their fields (see below), expressed in permissions. 

Data classes are groups of objects which play a role in the software application. 
To design a software application, the first step is to translate the real world items in a 
30 model by means of analysis. This comprises identifying the data classes, normalizing 
the data classes (i.e. delete repetitive groups and redundancy) and identifying the 
relations between the data classes. 
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For the present system and method for building a software application, data 
classes are described in the application specification 10 using a number of 
characteristics, such as: 

• a name; 

5 • the name of the database and the name of the database table where data about actual 
objects are stored; 

• a parent data class; 

• order in which data classes are shown (if nothing is specified, data classes will be 
presented in alphabetical order). 

10 • a size of a data class; 

• a primary show field. 

By identifying a parent data class (optional), a hierarchical structure of data 
classes can be defined. Child classes inherit the fields and relations from their parent. 
For this invention, an important characteristic of the data class is the size of the 
15 data class. This is the number of (expected) objects and determines the manner in 

which the data class is shown to the user. Options are: 'none', 'small', 'medium* and 
'large'. 

Another main characteristic for the data class is the primary show field, which 
has to be one of the fields of the data class. The primary show field allows an object to 

20 be discriminated from other objects by a user, better than the technical key of an object. 
The value in this field will be used as a label in a tree representation of an object. The 
primary show field is also important in relations between objects. Suppose that a data 
class A comprises a field F, which defines a relation to (the key field of) foreign class 
B. At runtime there can be an object a of data class A, having a relation to an object b 

25 of data class B. This means that the actual value of field F in object a is the value of the 
key field of object b. However, when object a is shown to a human user, the value of 
the primary show field of object b is shown as the value of field F, because this usually 
makes more sense to a human, then the value of the (technical) key field of object b. 
In case of a many-to-many relationship between data classes, an intermediary 

30 data class is specified, and marked as a 'relation class' (also known as an 'association 
class' in object oriented modelling). A relation class has no fields, it only has two 
connected classes. Data about objects in a relation class is stored in a specific system 
table, that does not have to be specified. 
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For each data class categories can be specified. Categories group data which are 
related to a data class. This can relate to fields or other data classes which are linked to 
the current data class. On output devices, such as screens, categories maybe shown as 
paragraphs, as nodes in a tree, as separate tab sheets in a collection of tab sheets, as 
independent screens, etc. In another form of output (in a text file or on a printer) 
categories can be shown as paragraphs. 

Categories are included in the regular specification 7 with a number of 
characteristics, such as: 

• a name; 

• a content type of the category; 

• a content class; 

• order in which categories are shown (if nothing is specified, categories will 
be presented in alphabetical order); 

• a presentation type: values may be: f as paragraph', 'in tree', 'on tab' or 'own 
window'. When no presentation type is specified, the generic application 
engine chooses 'on tab* as default. 

There are two possible content types: 'fields', which means that the category 
comprises. fields that are associated with the data class; or 'connected objects', which 
means that the category comprises the related objects of a connected data class. 

A content class has to be specified only when the content type is 'connected 
objects'. The content class specifies from which data class the objects have to be 
selected. As content class can be chosen: a connected class of the current data class, or 
a data class that is connected to the current data class by means of a relation class. In all 
descriptions below, a data class that is connected through a relation class, is handled in 
the same manner as a regular connected class. 

For each data class a number of fields can be specified. Fields are used as the 
basic elements for storing data within a software application. For each field 
characteristics may be specified, such as: 

• a name; 

• a long label (the long label being shown when fields are presented one at each.row); 

• a short label (the short label may be used as column header when objects are 
presented in a tabular form); 

• a data type, such as string, integer, graphic; 
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an indication that the field is part of the technical key, which allows the unique 
identification of objects; 
a description of the field; 

input instructions for the field (instructions for inserting or updating values); 
order in which fields are shown (if nothing is specified, fields will be presented in 
alphabetical order); 
a domain (see below); 

a foreign class and, if needed, a foreign field (see below); 
a deduction rule (as a computational specification 8); 
a dynamic lookup list (as a computational specification 8); 
• the name of the database column where the value of this field is stored (this column 
should be part of the database table as specified for the current data class) . 
To define one-to-one or one-to-many relationships between data classes, a field 
may comprise an identification of a foreign class. The foreign class has to be one of the 
other data classes as described in the application specification. As a result, the current 
data class will become a foreign class (in case of a one-to-one relation) or a connected 
class (in case of a one-to-many relation) of the data class that is specified as the foreign 
class. A foreign field might be specified too. When no foreign field is specified 
explicitly, the primary key field of the foreign class is the foreign field implicitly. The 
foreign field of the objects of the foreign class holds the possible values for the current 
field. Such a mechanism is usually known as a 'foreign key constraint' or 'referential 
integrity*. The kind of relationship (one-to-one or one-to-many) is specified by 
specifying the multiplicity. 

In a separate section of the specification of a data class, the roles of fields in 
relation to the current data class are specified. Here also fields of other data classes can 
be added, as far as there is an unambiguous (indirect) relationship between the current 
data class and the data class that owns the additional field. In case of a select or a read, 
the generic application engjine applies the necessary joins automatically. In case of an 
insert or an update, the genferic application engine diverts the data automatically to the 
correct database tables. The total of own fields and additional fields is called 'the 
associated fields* of a data'class. 

For each associated field, its role can be specified, e.g.: 
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• It can be specified if the field can be used for creating selection criteria when 
searching or selecting objects from the data class. A field can set to be a 'primary 
selection field', which means that the field is shown directly to be used in selection 
criteria when searching for objects of the data class. A field can set to be a 
5 * secondary selection field' when the field can be chosen from a pick list in second 

instance before it can be used for creating selection criteria. 

• The field can be linked to a category. The category must be one of the categories of 
the current data class, or a default category. 

• It can be specified whether the field will be shown as a column when the objects of 
10 the data class are represented in a table. 

• It can be specified whether the field can be used in a cross table representation, 
including the role: as columns, as rows, or as cell content. 

Domains maybe defined separately in the application specification. Domains 
comprise allowed values for fields. E.g. a day indication of a date field will be limited 
15 to the values 1-3 1 . A domain may be valid for multiple fields. For each domain an 
interval type has to be specified. An interval type may be 'not ordered', 'discrete' or 
'continuous'. The values in a domain having a 'not ordered' interval type, have no 
mutual relationship. This is usually the case in 'string' type data, e.g. Tails', 'London', 
'Berlin'. The values in a domain having a 'discrete* interval type have a mutual 
20 ordering, e.g. '1 :bad*, '2:mediate', '3:good\ Note that each domain value can comprise a 
key, such as '1' and a label such as 'bad'. The set of keys contain the allowed values 
for the field in actual objects. The label specifies the value as it will be presented to the 
human user. A 'continuous' interval type is like a 'discrete* interval type, but the 
domain is only used in select actions, not in modification actions. This means that the 
25 actual values of the fields in the objects are continuous. E.g. when the values in a 

domain with a 'continuous' interval type are '0:at the beach, 'O.lxlose to the beach', 
'1.0:not far from the beach', the actual values of objects could be e.g. 0.2 or 0.8. 
However, users use the labels (e.g. 'at the beach') in select actions, instead of the 
numbers. 

30 When a select action is performed with selection criteria containing a field with a 

discrete domain or a continuous domain (both are referred to hereinafter as 'ordered 
domain'), the selection is performed in two steps. In a first step the criteria with a 'not . 
ordered' domain are applied first, resulting in a subset of objects. In a second step the 
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resulting subset is ordered by a score. For each object this score is (a function of) the 
distance between the desired value in the selection criterion for the field that has the 
ordered domain, and the actual value of the field of the object. If more then one field 
with an ordered domain is involved in the selection criteria, the total score for each 
5 object, will be the total of the individual scores for the fields. 

User groups are groups of users (actual persons using a (graphical) user interface) 
or other software applications or hardware systems, which share the same permissions 
relating to data classes. User groups may also be modelled using hierarchical 
relationships (child-parent relations). Child user groups inherit the permissions of their 
10 parent user group. 



'user class*. The object representing the user (data) is called the 'user object'. 

Permissions, in the form of grants or authorisations, specify what a certain user 
15 group is able to do with certain data (and thus implicitly what they are not allowed). 



20 • export permission: specifies if a user group is allowed to export data about objects 
of a data class to file, possibly also which fields may be exported; 

• read permission: specifies if a user group may read objects of a data class, possibly 
also which fields can be read; 

• update permission: specifies if a user group may update objects of a data class, 
25 possibly also which fields may be updated; 

• insert permission: specifies if a user group may insert new objects to a data class, o 
on field level, which fields may be entered in a new object. Once the object is 
stored, a new access to the object is governed by the update permission; 

• copy permission: specifies if a user group may copy objects of a data class, and 
30 store the copy in the database; 

• delete permission: specifies if a user group may delete objects of a data class. 



Individual users of the software application are always known to the generic 
application engine as regular objects of a regular data class. This class is called the . 



Permissions are stored in the regular specification 7 using permission matrices. 
Permissions may include: 

• select permission: specifies if a user group is allowed to select objects of a data 



class, possibly also which fields may be used for the selection; 
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On data class level all above mentioned permissions can be specified. On field 
level only the first five permissions can be specified. If a permission is specified on 
field level, this always overrules the specified permission on data class level. 

The permissions in the permission matrices can have one of the following values: 

• no: the user group does not have the permission for the data class or the field; 

• yes: the user group does have the permission for the data class or the field; 

• 'follow foreign object* (ffo): the permission is dependent on the permission which is 
valid for the current foreign object. The current foreign object is the last object that 
was selected by the user on the route to the current object (more formally, it is the 
object that was last added to the context, see below). The value 'ffo' may be useful 
in the case of multiple facts which may be considered as facts of a data class, but 
for which (for reasons of normalisation) a connected class has been created, e.g. 
when the e-mail addresses of a person have been grouped in a separate data class 
having fields 'type' and 'address 1 . When a read permission has the value 'ffo', at run 
time the generic application engine uses the value which is valid for the read 
permission of the foreign object. When an update, insert, copy or delete permission 
has the value 'ffo', the generic application engine uses the corresponding value for 
the update permission of the foreign object, 'ffo' can not be specified for a select or 
export permission. 

20 • own: the permission depends on relations between the current user object and the 
current data object. The current data object is the object that is (going to be) read 
from a database (in case of a select permission) or is already loaded in the software 
application (in case of the other permissions). When 'own* is chosen as value, also 
the relationship(s) that express the 'own 7 relation have to be specified. E.g. the 

25 'own* relation might be expressed as a direct relation from the user class to the 

current data class. In another case, both the user class and the current data class 
might have a relation to the same foreign class. All other relationships between 
classes can be used in the specification of the 'own' relation too. The generic 
application engine grants the current user the permission when the user object and 

30 the current data object actually are related according to the specified relationship(s). 

• constraint: the permission is governed by a specific constraint: for all objects for 
which the constraint is met, the permission is 'yes', for the others it is 'no'. The 
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constraint is defined in another part of the application specification, the 

computational specification 8 (see below). 
One of the last steps in creating the regular specification is adding other basic 
functionality, e.g. user authentication, sending e-mails, registering incoming e-mails, 
etc. This is done by mapping the standard built-in functionality of the generic 
application engine to the relevant fields of the data model (e.g. the fields where user 
name and password are stored, respectively the e-mail field). In the area of component 
based development, this is known as 'deployment'. 

The computational specification 8, adding additional functionality to the software 
application, may comprise sequences, conditions and/or iterations. There are three 
kinds of computational specifications: 

• Flow chart: a flow chart is a structured manner to describe how the value of a 
variable may be deduced. Using sequences, conditions and iterations, the steps for 
determining the value of a variable are described. Each flow chart will result in the 
determination of the value of one or more variables (the output variables). A flow 
chart may be used to specify how a value of a field can be deduced from other data, 
like (other fields of) the current object, the context (see below) or the user object. A 
flow chart may also be used to specify how data modifications may be validated; 
• Constraints: a constraint is an expression which may be used to pose an additional 
restriction on objects of a data class. Such a constraint posed on a data class will 
result in a subset of all objects of that data class. A constraint may comprise 
multiple constraints combined by Boolean operators. A constraint can be used to 
specify how the content of a lookup list may be deduced dynamically, depending on 
the actual data and the user object. A second usage of a constraint can be the 
specification of a permission rule that can not be described in a matrix 
representation. Here again, the actual data and the user object can be used in the 
constraint specification; 
• Macro's: a macro is a collection of statements which may be executed in sequence, 
possibly accompanied by process logic (conditions and iterations). A macro may be 
executed in response to an action on an object. Then it is also called a trigger. 
Triggers may be defined when creating an object, when retrieving an object from a 
database, when updating a value of an object within the software application, when 
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inserting, deleting or updating an object in a database, or when exporting an object 
to file. A macro may also be executed on request from a user. 
One of the key elements of the current invention is the fact that from the 
application specification as described above, the generic application engine 5 is able to 
construct all interfaces, windows and screens that are used by users for interacting with 
the software application and its data. In the following, a description is given how the 
screens could be deduced from the application specification. A similar mechanism may 
be used for the program-to-program interface or for the output to text files or printers. 

The basic building block of a software application is a class manager. A class 
manager provides the functionality to present the objects from a data class in a simple, 
tree and/or tabular representation, to allow a user to select objects from the specific data 
class, to present the details of an object, and to modify objects. While updating values 
of objects, default values, input instructions, input aids and/or input validations can be 
applied. 

15 From a main menu a user can have direct access to all class managers for data 

classes he/she has select permission to. From the first class manager other class 
managers can be reached by hyperlinks or buttons. 

A class manager always has one corresponding data class, called the 'main class'. 
Besides objects from the main class, it can hold data from other data classes too. These 
20 other data classes are always (indirect) connected classes of the main class, specified 
with means of categories of content type 'connected objects'. 

The size of the main class determines how the class manager presents objects on 
a screen. When the size of the main class is 'none 1 , then the data class contains no 
objects or fields, but only relations to connected classes by its categories. When the size 
25 of the main class is 'small 1 , the class manager shows a tree at the left side of the screen. 
The top node of the tree will have a label like 'All objects'. As child nodes, all objects 
of the data class are represented (with respect to read permissions) by their value of the 
primary show field. When the size of a data class is 'medium' or 'large', objects can only 
be found by searching. Whpn the user selects such a data class, the class manager 
30 presents a screen to enter selection criteria. These selection criteria have to be 

constructed from the associated fields of the data class that are marked as a (primary or 
secondary) selection field. After applying these criteria, the objects that meet these 
criteria will be presented in a table, and from there, the details of each object can be 
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accessed, e.g. by selecting a row and/or activating a button. The details will be shown 
in a new window. 

Also, the presentation type of a category as defined in the application 
specification determines the presentation. When at least one of the categories of a data 
5 class has the presentation type € in tree', the screen will show a tree on the left side. 
There are the following options: 

• The main class has size 'small* . In this case, there already is a tree as described 
earlier. 

" • The main class has size 'medium' or 'large. In this case the uppermost node in the 
10 tree is the value of the primary show field of the current object. 

• The main class has size 'none* . In this case the uppermost node in the tree is the 
name of the data class. 

Whenever a node, representing an object (or the data class with size 'none*) is 
selected, details are shown on the right side of the screen: first the fields of the default 
15 category, followed by the categories that have to be presented as paragraphs, followed 
by tab panels for each category which have to be presented on tabs. The presentation of 
a category itself depends on its content type. When the content type is 'fields', the 
fields associated with the category are shown, one at a row. Each row starts with the 
long label of the field, followed by the value. When the content type is 'connected 
20 objects', a table will be shown with a row for every relevant object. Note that when the 
size is 'none', no fields can be specified. 

The categories with presentation type 'in tree', will be shown as separate nodes 
under the nodes that are representing an object (or the data class with size 'none'). The 
name of the category will be used as label. 
25 • Selecting a node that represents a category with content type 'fields', will show the 
fields of the category on the right side of the screen. 
• Selecting a node that represents a category with content type 'connected objects' 



When there is no tree representation (there is no data class with size 'small', and there 
is no category with presentation type 'in tree'), all categories will be presented in the 
same manner as described above. 



30 



will result in an empty right side of the screen. However as child nodes of this node, 
the user will find ail the associated objects from the connected class as separate 
nodes. For all these objects, the same may be repeated. 
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Categories with presentation type 'own window' can be reached by activating a 
button. The content will be presented in another window. 

The characteristics of the field may also influence the presentation on the screen. 
The long label of a field may be shown in front of the field value, as well as a possible 
5 description (as a tool tip) or a possible input instruction. The data type of a field 

determines the associated screen object When a domain or a foreign class is specified, 
the field is usually represented using a lookup list. When the size of a foreign class is 
'large', only the current value of the field is shown, accompanied by a button or link 
that brings the user to a search screen allowing to select a new object from the foreign 
10 class. 

From every row in a table representation, the user can visit all details from the 
data in that row, e.g. by selecting a row and/or activating a button. The details will be 
shown in a new window. When a field or table cell comprises a reference to a foreign 
object, this is automatically represented using a hyperlink, linking to the details of that 
15 object. These hyperlinks are only shown when the user has read permission on the 
foreign object. 

Also, permissions determine the appearance of the software application. 
Depending on permissions of the current user, some (select) fields, or columns in tables 
will be shown and others not. Permissions are also applied on all objects and actions on 
20 objects. E.g. insert, delete, copy, or save buttons will show or hide automatically, 
according to the permissions. 

As described above, the generic application engine automatically derives a 
presentation for all data and actions. However, all users are allowed to change the 
presentation, according to their own preferences. At runtime, they can sort tables, they 
25 can change the order of fields, they can change the presentation type of categories, they 
can hide or show columns in tables, etc., all with respect to the specified permissions. 
All modifications of the presentation can be stored for re-use. 

In summery, after entering an application specification into the generic 
application engine, a software application is created that allow users to select (search), 
30 read (from simple, tree and/or tab representations), restructure (sort, join) and modify 
(insert, copy, delete and update) all data in the software application, exactly according 
to the user's permissions. This functionality is provided in a web interface (HTML) 
and/or in a windows interface. 
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Using a web interface, the appearance of the software application may be adopted 
to the user's need by using an appearance specification 9. The generic application 
engine creates all screens to be displayed to the user as XML documents (extended 
Mark-up Language). These XML documents may be transformed to HTML 
5 (HyperText Mark-up Language) using a XSL-document (extensible Style sheet 
Language) and/or CSS (cascading style sheets). With XSL, screen objects may be 
positioned or replaced and with CSS layout characteristics may be changed, such as 
background, colour and/or font. 



10 might be relevant for the actual realisation of the generic application engine, but, as 
such, these are not new and already known in the area of data processing. They are 
omitted from this description, since they will be apparent to the person skilled in the 
art. 



15 context is passed. A context contains an ordered list of all objects which were passed 
by the user (in several class managers) to arrive at the present class manager from the 



stored in the context. 

When a class manager is also holding data for connected classes, the current 
20 object of the main class (the 'main object*) is also added to the context for all 

operations on objects of the connected classes. Also the relation from the current main 
object to the current connected object is added to the context. 

When the class manager also holds objects of indirect connected classes, all 
intermediary objects and relations are also added to the context, for all operations on 
25 the objects of the indirect connected classes. 

The user may decides to switch to another class manager, which shows details of 
an object or shows a category with presentation type *own window*. In these cases the 
context as constructed so far (with the list of objects and relations) is passed to the next 
class manager. 

30 A class manager may use a context in different ways. First, a context can be used 

' to apply additional constraints on objects (e.g. only showing objects which are valid 
within the present context). In order to define if an object from a data class meets the 
constraints defined by a context, first all relations from this data class as connected 



The application specification may comprise a lot of other characteristics, which 



Internally, every time a class manager is called from another class manager a 



starting point of the software application. Also the relations between the objects are 
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class (multiplicity *) to the data classes in the context as foreign class (multiplicity 0..1) 
have to be listed (according to the application specification). An object meets the 
constraints, only if for all these relationships, there actually is a relation from this 
object to the objects in the context. This mechanism is applied when a class manager 
shows the connected objects of an object in a table or tree. 

The context can also be used to apply additional constraints on lookup lists which 
are constructed from objects of a foreign class. In this case only a subset of all objects 
from the foreign class are shown as options, only those that are valid within the present 
context. The same rule as above is applied to define whether an object meets the 
constraints defined by a context. 

Furthermore, the context can be used for adding default values for newly defined 
objects. In this case the class manager will add relations to the objects in the context ( 
automatically, as far as there are relations specified from the data class of the new 
object as connected class (multiplicity *) to the data classes of the objects in the context 
as foreign class (multiplicity 0..1). 

In the application specification it can be defined whether the context has to be 
applied (or not) in all above cases. 

Finally, a context can be used in the execution of computational specifications, 
such as deduction rules or permission rules. 

The foundation of the generic application engine is the subject of patent 
application PCT/NLO 1/00926 of the inventors of this patent application, which is 
incorporated herein by reference. In patent application PCT/NL01/00926, the term 
'configuration' is used which corresponds to the term 'application specification' as 
used in the present patent application. The term 'entity' in PCT/NL01/00926 
corresponds to the term 'data class' as used in the present patent application; the term 
'attribute' in PCT/NLO 1/00926 corresponds to the term 'field' as used in the present 
patent application. The 'object search' and 'object editor' functionalities as described 
in PCT/NL01/00926, are integrated in the 'class manager'. A 'context' is now 
understood to comprise an ordered list of all objects which were passed by the user to 
) arrive at the present obj ect (via several class managers), plus the indication of the 
relationships between the objects. 

For the technical implementation of the generic application engine, two strategies 

can be chosen: 
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• Strategy 1 is interpretation. In this case the application specification is loaded into the 
generic application engine. The generic application engine interprets the content of the 
application specification, and shows the desired behaviour to the outside world. 

• Strategy 2 is compilation. In this case the application specification is loaded into the 

5 generic application engine. The generic application engine first reads the content of the 

application specification, and compiles (parts of) the application specification to 
executable program code, that will run together with standard components of the generic 
application engine. 

The pros and cons of these strategies are well known in the field op data processing, and 

1 0 therefore not further described in this document. 

An example of the present system and method for building a software application 
is given below. The example shows how to develop a reservation application for 
(holiday) house rentals, in which private home owners offer their homes via a local 
agent. The software application has to support this via the Internet. 

1 5 The software application is realised using the specification editor 4. First, the 

software application is given a name, and some general characteristics are given. In a 
second step, the data classes are specified. From an information analysis, the following 
data classes are found in the rental process: 

• Homes 

20 Data concerning the homes, such as the address, number of persons allowed, a picture, 

the owner, etc. 

• Rentals 

Data concerning the rental periods during which the home is available, as well as the 
rental cost and whether the home is rented during a specific period. 
25 • Persons 

Data related to the various actors in the process. These include name and address data, 
but also role indication, user names and passwords. 

The next step is to specify the fields and domains of the various data classes. For 
each field, a name, data type, description, input instructions and domain or foreign class 
30 (when relevant) is indicated. Then, for each data class, the following is specified: the 
mutual order of the fields, the primary show field, which fields can be used as primary 
(P) or secondary (S) selection criteria, which fields must be shown in a table after a 
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select action, which fields are used for sorting the table (ascending or descending), 
which fields are mandatory, and in which categories the fields must be presented. 

For the data class "Homes' this results in the following entry in the regular 
specification 7. Note that not all field characteristics are shown. 



field name 


data type 


select 
field? 


show in 
table? 


sort 


mandatory 


domain 


foreign 


category 


Reference number 


Integer 








V 






Core data 


Name 


String 


S 


Y 




V 






Core data 


Picture 


Graphic 




Y 










Core data 


Short descrintion 


String 




Y 




V 


• 




Core data 


Description 


Memo 














Core data 


Max. no. persons 


Integer 


P 


Y 


A 


V 


Number 




Core data 


No. bed rooms 


Integer 


S 






V 


Number 




Core data 


Distance to town (km] 


Integer 


S 












Add. info 


Child friendly 


Boolean 


S 












Add. info 


Price starting from 


Currency 


s 








Price 




Add. info 


Street 


String 








V 






Address 


Zip code + City 


String 








V 






Address 


Country 


String 


p 


Y 


A ' 


v 


Countries 




Address 


Tel. Agent 


Integer 








V 






Contact data 


Agent 


Integer 


s 






V 




Persons 


; Contact data 


Owner 


Integer 


s 






V 




Person! 


; Contact data 



10 



•Reference number' is indicated as the unique key field, 'Name' as primary show 
field. The fields 'Price starting from' and 'Tel. agent* are deduced fields, which are 
deduced using a computational specification 8. 

The domain 'Countries' comprises all relevant countries, e.g.: 



countries 


NL 


Netherlands 


BE 


Belgium 


NA 


Namibia 


BR 


Brazil 



The domain 'Price' is a continuous domain, like '500, cheap', ' 1000, average' 
15 and ' 1 50, expensive'. This provides the possibility to let users create selection criteria 



PCT/NL 



0 2 ^luao • 



4 



23 



based on the three labels, but presenting all results, ordered on the closeness of the 
match. 

In the field 'Agent* a dynamic lookup is defined as a computational specification, 
as it is meant that only agents are shown which have indicated to be active in a specific 
country. 

For the data class 'Homes* four categories with content type 'fields' are 
specified: 'Core data*, 'Add. info\ 'Address* and 'Contact data*. Furthermore one 
category 'Rentals' is specified. This category has content type 'connected objects' and 
'Rentals' as content class. As a result, all rentals related to a home, will be presented in 
a table on a tab panel. 

As a next step, user groups are specified. From a further analysis of the actors, the 
following user groups are identified: 

• Customers 

• Owners 

• Agents 

• Manager 

As the next step, the permissions for user groups and data classes are specified. 
(Export and copy permissions are omitted in this example.) 





Homes 


Rentals 


Persons 




a 


(X 

& 


o 


» 
P. 


BS 

3* 
1 


3" 

on 


delete 


si 

3. 


a 
» 

CL 


c 

0 

a. 

n 


insert 


D. 

ST 
9 


2L 


» 


H 

a 

1 


a) Customers 


N 


N 


Y 


C 


N 


Y 


N 


N 


F 


N 


O 


N 


o 


o 


o 


b) Owners 


O 


O 


Y 


C 


O 


N 


N 


O 


F 


N 


O 


N 


o 


o 


o 


c) Agents 


o 


O 


Y 


C 


O 


O 


O 


0 


F 


O 


O 


N 


o 


o 


o 


d) Manager 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 


Y 



legend: 
Y = yes : 
N = no 

F = follow foreign object 
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O = own 

C = constraint 

For the user group 'Customers' it is indicated that they are allowed to select 
objects from the data class Homes' and that they are allowed to view data related to 
these objects. Customers are not allowed to see homes in the database which are 
marked 'screened off. This is specified in a computational specification in the form of a 
constraint. As a consequence, customers are also not allowed to read rentals related to 
the homes mat are screened of. This is expressed by a follow foreign object permission 
value. Customers may also insert reservations. Customers may also insert, read and 
update their own data. On field level it may be indicated which fields from these data 
classes they are not allowed to use as a selection criterion or which they are not allowed 
to view. 

For the user group 'Owners' the same permission rights are specified as for the 
'Customers'. Moreover, they are allowed to read all homes, to insert homes, to delete 
homes, and to update data concerning homes, but only for their own homes. The 
generic application engine knows from the data model that there are relations from the 
data class 'Homes' to the data class 'Persons' (via the fields 4 Agent' and 'Owner'). If 
the current user actually is related to the current home, the generic application engine 

grants the user the additional permissions. Furthermore, on a field level it may be 

indicated which fields may not be updated. Owners are also allowed to select rentals, 

but again, only their own. 

For the user group 'Agents' the same permissions are defined as for the user group 

•Owners'. Moreover, they are allowed to add or delete objects in the data class 'Rentals', 

but only for the homes of owners they represent. 

For the user group 'Manager* it is indicated that they have all permissions for each 

data class, allowing the 'manager' to select, read, insert, delete and update data in all 

data classes. 

As a next step, triggers may be entered, defined in the form of macro's. This 
software application has two triggers: 

• Once a customer makes a reservation, an e-mail must be sent to the associated agent. 

• Once the agent confirms the reservation, an e-mail must be sent to the customer and 
(when desired) to the owner. 
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Next, validation rules may be entered in the application specification, relating to 
constraints for input data, e.g. check for double rental in a certain period. These ; 



validation rules may have the form of a flow chart in the computational specification. 
After finishing the specification of data classes and fields, the generic application 
5 engine is able to build a database 6 which suits the application specification just 



As a final step, the default layout may be altered to a desired layout using the 
form specification 9. 

Using this procedure, it is possible to have a working software application within 
10 a very limited amount of time. As soon as fields are specified, it impossible to test 
whether the software application suits the requirements, by entering the application 
specification in the generic application engine and review the running software 
application. New ideas or possibilities may be directly included in the application 
specification, tested and allowed or dismissed. 



developed. 
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CLAIMS 



1. System for building a software application comprising an input/output device 
(22), memory means (21) and processing means (20) connected to the input/output 
5 device and memory means, the processing means (20) being arranged for defining an 
application specification (10), which allows execution of the software application by 
entering the application specification (10) in a generic application engine running (5) 
on a computer system, characterised in that the processing means (20) are further 
arranged to derive the application specification (10) using the input/output device (22), 
10 and to store the application specification (10) in the memory means (21), 
the application specification (10) comprising: 

a) a specification of a plurality of data classes relevant within the software 
application, a data class being a description of objects, and the plurality of data classes 
forming a structure by means of relations; 
15 b) a specification of at least one user group of the software application, a user 

group.being defined as a group of users having common roles with regard to the 
software application; 

c) an assignment of permissions to the at least one user group with respect to the 

plurality of data classes. 

20 

2. System according to claim 1, in which the application specification (10) further 
comprises for each of the plurality of data classes a specification of a plurality of fields, 
each field representing an element for storing data values related to an object. 

25 3. System according to claim 1 or 2, in which the application specification (10) 

further comprises for each of the plurality of data classes a specification of a plurality 
of categories, which can be used to structure all data related to an object. 



30 



4. System according to claim 1, 2 or 3, in which the application specification (10) 
further comprises a specification of a plurality of domains, a domain being a list of 
lookup values that can be referenced to from the specification of fields. 
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5. System according to claim 1, 2, 3 or 4, in which the permissions are chosen 
from the group of: select permission; export permission; read permission; update 
permission; insert permission; copy permission; delete permission. 

6. System according to one of the claims 1 through 5, in which the value of each 
permission is one of the group of: no; yes; follow foreign object; own; constraint. 

7. System according to one of the claims 1 through 6, in which the processing 
means (20) are further arranged to append a computational specification (8) to the 
application specification (10) for describing further computational parts of the software 
application. 

8. System according to one of the claims 1 through 7, in which the processing 
means (20) are further arranged to append an appearance specification (9) to the 
application specification (10) for defining non-functional parts of the software 
application, such as user interface parts. 

9. System according to one of the claims 1 through 8, in which the processing 
means (20) are further arranged to store the application specification (10) in the 
memory means (21) as an XML file. 

10. Method for building a software application by defining an application 
specification (10), which allows execution of the software application by entering the 
application specification (10) in a generic application engine (5) running on a computer 
system, characterised in that the method comprises the step of deriving the 
application specification (10) the application specification (10) comprising 

a) a specification of a plurality of data classes relevant within the software 
application, a data class being a description of objects, and the plurality of data classes 
forming a structure by means of relations; 

b) a specification of at least one user group of the software application, a user 
group being defined as a group of users having common roles with regard to the 
software application; 
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c) an assignment of permissions to the at least one user group with respect to the 
plurality of data classes. 

1 1 . Method according to claim 10, in which the application specification (10) 
further comprises for each of the plurality of data classes a specification of a plurality 
of fields, each field representing an element for storing data values related to an object 

12. Method according to claim 10 or 1 1, in which the application specification 
(10) further comprises for each of the plurality of data classes a specification of a 
plurality of categories, which can be used to structure all data related to an object. 

13. Method according to claim 10, 1 1 or 12, in which the application 
specification (10) further comprises a specification of a plurality of domains, a domain 
being a list of lookup values that can be referenced to from the specification of fields. 

14. Method according to claim 10, 11, 12 or 13, in which the permissions are 
chosen from the group of: select permission; export permission; read permission; 
update permission; insert permission; copy permission; delete permission. 

15. Method according to one of the claims 10 through 14, in which the values of 
each permission is one of the group of: no; yes; follow foreign object; own; constraint. 

16. Method according to one of the claims 10 through 15, in which the 
application specification (10) further comprises a computational specification (8) for 
describing further computational parts of the software application. 

17. Method according to one of the claims 10 through 16, in which the 
application specification (10) further comprises an appearance specification (9) for 
defining non-functional parts of the software application, such as user interface parts. 

1 8. Method according to one of the claims 10 through 17, in which the 
application specification (10) is stored as an XML file. 
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19. Computer program product comprising an application specification (10) as 
obtained by the system according to one of the claims 1 through 9, or the method 
according to one of the claims 10 through 18, which when input in a generic 
application engine (5) running on a computer system, provides the computer system 
with the functionality of the software application associated with the application 
specification (10). 

********* 




v * / uuoe a 



ABSTRACT 



System and method for building a software application by defining an application 



specification (10) which allows execution of the software application by entering the 
5 application specification (10) in a generic application engine (5) running on a computer 
system. To this end, the application specification (10) comprises a specification (7) of a 
plurality of data classes relevant within the software application, a data class being a 
description of objects, the plurality of data classes forming a structure by means of 
relations, a specification of at least one user group of the software application, a user 
10 group being defined as a group of users having common roles with regard to the 

software application, and an assignment of permissions to the at least one user group 
with respect to the plurality of data classes. 
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documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 



□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




LINES OR MARKS ON ORIGINAL DOCUMENT 



